A distributed transaction may include a set of processes or operations that may involve the use of more than one network host/resource. For example, a distributed transaction may call for database updates or operations using more than one database. A network host may provide for transaction resources utilized by a process, such as the database that requires updating and/or use. A transaction manager may receive a distributed transaction and prepare participating processes to execute on required network hosts. Thus, the transaction manager may prepare a coordinator network host/node that manages a set of participating network nodes each executing one or more processes of the distributed transaction.
Similar to other transactions, distributed transaction must maintain atomicity, consistency, isolation, and durability properties (ACID properties). Atomicity requires that changes made during processing a transaction are atomic, either all the changes to a database during an operation or update occur or they all do not occur. This prevents database updates from partially occurring, which would affect the reliability and consistency of databases. Thus, in the case of a system failure or a failure of a particular network host, the other network hosts executing their participating processes may not know the results of the transaction during recovery. Thus, these other network hosts may wait in a “ready to commit” state or keep a transaction resource locked until the failed network host can be contacted.